13.2.2　构建和分发镜像

考虑完安全性，我们开始构建和分发。本节介绍在构建和分发镜像时可能需要考虑的问题。

1．构建镜像

在构建镜像时，你可能需要考虑一些方面。

第一，尽管Dockerfile是标准的，但存在其他构建镜像的方法（见第7章），因此，如果各种方式可能引起混乱或彼此不兼容，则可能需要强制采用该标准。你可能还会有一个策略配置管理工具，希望与你的标准操作系统部署集成在一起。

我们的实际经验表明，Dockerfile方法在开发人员中深入人心并广受欢迎。学习更复杂的CM工具以符合公司针对虚拟机的标准，这种开销通常不是开发人员有时间或愿意承担的​​。为了方便和代码复用，通常使用诸如S2I或Chef/Puppet/Ansible之类的方法。支持Dockerfile将确保你从开发社区获得的问题和反馈减少。

第二，在敏感环境中，你可能不希望对所有用户开放镜像的构建，因为镜像可能会被内部或外部的其他团队信任。

可以通过适当的镜像标记或升级（见下文）或基于角色的访问控制来限制构建。

第三，开发人员的经验值得考虑。出于安全原因，并非总是可以使用户获得从公共仓库下载Docker镜像的开放访问权限，用户甚至不能获得在本地环境中运行Docker工具的能力（见第14章）。在这种情况下，你可能要采用几种选择。

• 获得标准工具的批准。由于业务的安全性挑战和需求，这可能成本很高，有时甚至成本太高。
• 创建一个可以在其中构建Docker镜像的一次性沙盒。如果虚拟机是暂时的、已被锁定并经过严格审计的，许多安全问题都会大大缓解。
• 通过任何Docker客户端提供对上述沙盒的远程访问（但请注意，这不一定会显著减少许多攻击面）。

第四，开发人员在部署应用程序时的体验一致性也值得考虑。例如，如果开发人员在其笔记本电脑或测试环境上使用docker-compose，则可能不愿转向生产环境中的Kubernetes部署。（随着时间的流逝，随着Kubernetes成为标准，这最后一点变得越来越无意义了。）

2．Registry

现在明显你需要一个Registry。有一个开源示例，即Docker Distribution，但它不再是主要的选择，这主要是因为Docker Registry就是一套公开的API的实现。现在，如果你想为企业Registry付费，或者想自己运行一个开源软件，则可以选择多种产品。

Docker Distribution是Docker数据中心产品的一部分，该产品具有一些引人注目的功能（如Content Trust）。

无论选择哪种产品，都需要考虑一些潜在的不太明显的要点。

• Registry与你的身份验证系统配合使用吗？
• 它是否具有基于角色的访问控制（RBAC）？

身份验证和授权对企业来说意义重大。一个快速且便宜的、所有人可免费使用的Registry在开发中可用，但是如果你要维护安全性或RBAC标准，则这些要求将成为你的首要任务。

某些工具的RBAC功能粒度较差，如果突然发现自己已被审计并发现不足，这可能是一个很大的漏洞。

• 它有升级镜像的方法吗？ 并非所有镜像都是一样的。有些是快速但不完善的开发实验，其中不要求正确性，而另一些则用于真实的生产环境。组织的工作流程可能要求你区分两者，Registry 可以通过管理不同实例上的流程或者对标签进行强制来帮助你。
• 它与你的其他制品存储库是否可共存？ 你可能已经有一个制品存储库来存储TAR文件和内部软件包等。在理想的情况下，你的Registry只是其中的一个功能。如果不能达成，那么应该意识到集成或管理将是一笔开销。

3．基础镜像

如果你在考虑标准，团队可能需要使用一些基础镜像。

第一，你要使用什么，应该使用什么根镜像？通常，组织都喜欢使用标准的Linux发行版。如果是这样，那它很可能被要求作为基础。

第二，你将如何构建和维护这些镜像？如果发现漏洞，谁（或什么）负责识别你是否受到影响或哪些图像受到影响？谁负责修补受影响的资产？

第三，该基本镜像应包含哪些内容？是否所有用户都需要一套通用的工具，或者你想让各个团队自行决定？你是否要将这些要求分为单独的子镜像？

第四，如何重建这些镜像和子镜像？通常，需要创建某种流水线。通常，当一些触发器触发时，它将使用某种CI工具（如Jenkins）自动构建基础镜像（并随后从中构建任何子镜像）。

如果你负责基础镜像，则可能会经常遇到有关该镜像大小的挑战。人们通常认为，小的镜像更好。在某些方面（例如安全性），这可能会引起争议，但是这种“问题”与其说是现实的，不如说是幻想的，特别是在性能方面。这种情况的悖论性质在技巧60中进行了讨论。

4．软件开发生命周期

软件开发生命周期（Software development lifecyle，SDLC）是一个处理、创建、测试、部署和淘汰软件的过程。在理想状态下，SDLC通过确保在对资源池有共同利益的组内对软件进行持续评估、购买和使用来帮助提高效率。

如果你已经拥有SDLC过程，那么Docker如何适应？可能会陷入对Docker容器是一个软件包（例如rpm）还是整个Linux发行版进行的哲学讨论中（因为其内容可以在开发人员的控制下）。无论哪种方式，争论的重点通常都是所有权。谁负责镜像中的内容？这就是Docker的分层文件系统（见第1章）独有的地方。由于谁可以在最终镜像中创建内容完全可审计（假设内容是受信任的），因此追溯到谁负责软件栈的哪个部分相对简单。

确定责任后，你可以考虑如何处理补丁。

• 你如何确定哪些镜像需要更新？ 扫描器可以在这里提供帮助，或者可以使用任何工具识别可能感兴趣的制品中的文件。
• 如何更新它们？ 一些平台允许你触发容器的重建和部署（如OpenShift或者可能是手动操作的流水线）。
• 你如何告诉团队进行更新？ 电子邮件是否足够？还是你需要一个身份可识别的人来作为负责人。同样，你的公司政策可能会成为你的指南。对于已经部署的传统软件已经有了政策。

在这个新世界中，关键点在于负责容器的团队数量可能会比过去更多，并且要评估或更新的容器数量也可能会大大增加。如果你没有适当的流程来处理软件交付量的上升，那么所有这些都会给你的基础架构团队带来沉重的负担。如果一推再推，你可能需要强迫没排好队的用户在镜像上添加一层又一层来进行更新。如果你运行共享平台，这尤其重要。你甚至可以考虑使用编排工具将“淘气”容器放在特定的隔离主机上，以降低风险。通常，没有什么时间去考虑这些事情，必须立即给出答案。